Skip to content

Implement unstable trait impl #140399

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 23 commits into
base: master
Choose a base branch
from
Open

Implement unstable trait impl #140399

wants to merge 23 commits into from

Conversation

tiif
Copy link
Member

@tiif tiif commented Apr 28, 2025

This PR allows marking impls of stable trait with stable type as unstable.

Approach

In std/core, an impl can be marked as unstable by annotating it with #[unstable_feature_bound(feat_name)]. This will add a ClauseKind::Unstable_Feature(feat_name) to the list of predicates in predicates_of .

When an unstable impl's function is called, we will first iterate through all the goals in param_env to check if there is any ClauseKind::UnstableFeature(feat_name) in param_env.

The existence of ClauseKind::Unstable_Feature(feat_name) in param_env means an#[unstable_feature_bound(feat_name)] is present at the call site of the function, so we allow the check to succeed in this case.

If ClauseKind::UnstableFeature(feat_name) does not exist in param_env, we will still allow the check to succeed for either of the cases below:

  1. The feature is enabled through #[feature(feat_name)] outside of std / core.
  2. We are in codegen because we may be monomorphizing a body from an upstream crate which had an unstable feature enabled that the downstream crate do not.

For the rest of the case, it will fail with ambiguity.

Limitation

In this PR, we do not support:

  1. using items that need #[unstable_feature_bound] within stable APIs
  2. annotate main function with #[unstable_feature_bound]
  3. annotate #[unstable_feature_bound] on items other than free function and impl

Acknowledgement

The design and mentoring are done by @BoxyUwU

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 28, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@BoxyUwU BoxyUwU self-assigned this May 27, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Jun 10, 2025

☔ The latest upstream changes (presumably #142299) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pls add PR description providing an outline of the approach

apart from that, a few minor nits, after this r=me :3

Thank you for working on this ❤️

// enabled that we do not.
//
// Note: we don't consider a feature to be enabled
// if we are in std/core even if there is a corresponding `feature` attribute on the crate.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

future work: we likely want an #[rustc_allow_internal_unstable(foo)] attribute which only adds UnstableFeature clauses to the param_env, but not predicates_of.

@BoxyUwU BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 2, 2025

let mut err = self.dcx().struct_span_err(
span,
format!("unstable feature `{sym}` is used without being enabled."),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would try to mirror the existing errors for unstable library features if staged_api is not enabled

error[E0658]: use of unstable library feature `slice_partition_dedup`
 --> src/main.rs:3:7
  |
3 |     x.partition_dedup();
  |       ^^^^^^^^^^^^^^^
  |
  = note: see issue #54279 <https://github.com/rust-lang/rust/issues/54279> for more information
  = help: add `#![feature(slice_partition_dedup)]` to the crate attributes to enable
  = note: this compiler was built on 2025-07-02; consider upgrading it if it is out of date

not sure whehter you could even reuse the reporting machinery we already use for methods etc

Copy link
Member Author

@tiif tiif Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diagnostics can be reported through feature_err_issue, but it requires the issue number of the library feature. Unfortunately we don't have issue number information when we emit ambiguity error, and putting issue number into #[unstable_feature_bound] can be quite verbose because there can be multiple symbol at a time, for example: #[unstable_feature_bound(foo, bar)]

So I added feature_err_unstable_feature_bound in cf4770d, which is basically feature_err_issue but omitted the issue number note.

Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few more nits

@rustbot
Copy link
Collaborator

rustbot commented Jul 3, 2025

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Comment on lines +29 to +33
#[stable(feature = "a", since = "1.1.1")]
#[unstable_feature_bound(feat_bar)]
fn bar() {
Bar::foo();
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not error in current implementation, we probably should lint against this usage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as in, have an #[unstable_feature_bound(feat_bar)] on a stable item?

yeah. Please add a fixme for this somewhere

Comment on lines +156 to +162
if self.may_use_unstable_feature(param_env, symbol) {
return self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes);
} else {
return self.evaluate_added_goals_and_make_canonical_response(Certainty::Maybe(
MaybeCause::Ambiguity,
));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if self.may_use_unstable_feature(param_env, symbol) {
return self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes);
} else {
return self.evaluate_added_goals_and_make_canonical_response(Certainty::Maybe(
MaybeCause::Ambiguity,
));
}
if self.may_use_unstable_feature(param_env, symbol) {
self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)
} else {
self.evaluate_added_goals_and_make_canonical_response(Certainty::Maybe(
MaybeCause::Ambiguity,
))
}

@@ -20,6 +20,7 @@ rustc_parse_format = { path = "../rustc_parse_format" }
rustc_session = { path = "../rustc_session" }
rustc_span = { path = "../rustc_span" }
rustc_transmute = { path = "../rustc_transmute", features = ["rustc"] }
rustc_type_ir = {path = "../rustc_type_ir"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please go through rustc_middle instead, it should reexport all of rustc_type_ir in ty

Comment on lines +775 to +780
#[allow(rustc::usage_of_type_ir_traits)]
if self.selcx.infcx.may_use_unstable_feature(obligation.param_env, symbol) {
return ProcessResult::Changed(Default::default());
} else {
return ProcessResult::Unchanged;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[allow(rustc::usage_of_type_ir_traits)]
if self.selcx.infcx.may_use_unstable_feature(obligation.param_env, symbol) {
return ProcessResult::Changed(Default::default());
} else {
return ProcessResult::Unchanged;
}
if self.selcx.infcx.may_use_unstable_feature(obligation.param_env, symbol) {
ProcessResult::Changed(Default::default());
} else {
ProcessResult::Unchanged;
}

cc @compiler-errors I don't think we should use the InferCtxtLike trait here. However, I can't think of a good place to put this.

We could make it a free function and use the reexport from rustc_middle, but 🤷 idk, also feels kinda iffy

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, I don't see why it shouldn't just be a free function. Why does it use InferCtxtLike today?

Comment on lines +851 to +853
return Ok(EvaluatedToOk);
} else {
return Ok(EvaluatedToAmbig);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return Ok(EvaluatedToOk);
} else {
return Ok(EvaluatedToAmbig);
Ok(EvaluatedToOk)
} else {
Ok(EvaluatedToAmbig)

Comment on lines +29 to +33
#[stable(feature = "a", since = "1.1.1")]
#[unstable_feature_bound(feat_bar)]
fn bar() {
Bar::foo();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as in, have an #[unstable_feature_bound(feat_bar)] on a stable item?

yeah. Please add a fixme for this somewhere

@@ -0,0 +1,15 @@
//@ aux-build:unstable_impl_coherence_inference_aux.rs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file is called tests/ui/unstable-feature_bound/unstable_impl_coherence_inherence.rs rn, not inference. and why call it coherence 🤔 this is more about method selection, is it not?

@compiler-errors
Copy link
Member

Could you please do a perf run before this lands too? The extra call to hir_attrs in predicates_of may need to be querifyied and/or some fast path might need to be added for perf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants